Semiautomatische Metadaten-Extraktion und Qualitätsmanagement in Workflow-Systemen zur Digitalisierung historischer Dokumente

Listing 7.1: Schnittstelle ’WordParser’ Schritt 3: Erstellung des Invertierten Indexes Sind Satzund Term-Index erzeugt, kann mit Hilfe dieser Datenstrukturen im dritten Arbeitsschritt des Klassifikations-Workflows nun ein dritter Index erzeugt werden. In diesem invertierten Term-Index (in Anlehnung an [Baeza-Yates und Ribeiro-Neto (1999)]) wird zusätzlich hinterlegt, in welchen (in Schritt 1 vom Sentencer erzeugten) Sätzen jeder (vom WordParser in Schritt 2 erzeugte) Term des Quelldokuments auftaucht. Dieser Arbeitsschritt ist in Abbildung 7.1 als Schritt 3 zu sehen. Die Klasse InvertedIndexer erzeugt Trefferlisten, die angeben, in welchen Sätzen im Satz-Index ein gegebener Term zu finden ist. Wie zuvor wird auch der invertierte Index in einer Kopfund Rumpf-Struktur abgespeichert, mit dem Unterschied, dass der n-te ganzzahlige Eintrag im Kopfteil nun einen Wert enthält, der codiert, in welcher Entfernung zum Anfang des Indexes die Trefferliste 78 Implementierung: Klassifikations-Framework für den n-ten Term aus dem Term-Index beginnt (vgl. Abschnitt 7.4). Schritt 4: Erstellung der Vektor-Datenbank Unter Verwendung der bisher erzeugen Index-Strukturen kann jetzt das Quelldokument effizient durchsucht werden. Es gilt nun, die kontextuellen Eigenschaften aller Terme des Quelldokuments zu analysieren. Dies entspricht Arbeitsschritt 4 im abstrakten Klassifikations-Workflow, wie in Abbildung 7.1 dargestellt. Die Schnittstelle Contexter hat die Aufgabe, den Kontext (wie definiert auf Seite 25) zu einem gegebenen Term zu extrahieren. Wie zuvor auch schon beim Sentencer und WordParser gibt es unterschiedliche Implementierungen, die in Abhängigkeit vom Quelldokument und dessen Domäne gewählt werden können. Eine mögliche Implementierung ist ein Contexter, der eine feste Anzahl von Termen rund um den zu untersuchenden Term als Kontext definiert (Klasse FixedWindowContexter). Nachdem der Kontext eines Terms in geeigneter Weise extrahiert wurde, gilt es dessen Eigenschaften zu analysieren und serialisieren. Diese Aufgabe wird von der Schnittstelle FeatureModule übernommen. Der Anwender kann dem Contexter eine Liste von FeatureModulen zuweisen, deren Analyse-Resultate dann im Kontext-Vektor gespeichert werden. In Kapitel 5 wurde dieser Vorgang ausführlich in der Theorie erläutert, die nachfolgenden Abschnitte gehen nun auf einige Implementierungsdetails ein. Innerhalb eines Kontext-Vektors werden die kontextuellen Eigenschaften eines Terms gespeichert, wie sie im gesamten untersuchten Text-Corpus auftauchen. Dazu extrahiert der Contexter zunächst den Kontext zu einem gegebenen Term und reicht diesen dann an eine Liste von FeatureModulen weiter, welche dann die Eigenschaften des Kontexts serialisieren. Ein FeatureModul untersucht den übergebenen Kontext auf eine bestimmte Eigenschaft (wie beschrieben in Abschnitt 5.2.3 auf Seite 44) und muss dazu lediglich eine schmale Schnittstelle erfüllen (zu sehen in Programmausdruck 7.2). Jedes FeatureModul hat eine einzigartige Identifikations-Nummer und weist jeder Eigenschaft, die während der Analyse 7.4 Implementierung 79 gefunden wird, eine innerhalb des FeatureModuls einzigartige Identifikationsnummer zu. Durch die Kombination der FeatureModul-Identifikationsnummer mit der Feature-Identifikationsnummer entsteht eine global eindeutige Identifikation für jede Komponente des Kontext-Vektors. Grafik 5.6 zeigt den schematischen Aufbau eines Kontext-Vektors. Die Vektoren werden nun ebenfalls in einem Header-BodyIndex gespeichert (beschrieben in Abschnitt 7.4), so dass man effizient auf den Kontext-Vektor für einen gegebenen Term zugreifen kann. 0 /∗∗ 1 ∗ an a ly ze t he g iven con t ext 2 ∗ 3 ∗ @param con t ext 4 ∗ @r e t u r n FeatureCategory 5 ∗/ 6 p u b l i c a b s t r a c t FeatureCategory analyzeContext ( S t r i n g [ ] context ) ; Listing 7.2: Schnittstelle ’FeatureModule’